Review meeting

每個sprint結束時，開發團隊要展示本此所完成的功能給客戶（或是客戶代表）看，讓客戶確定此次所開發的功能是否符合客戶期待。如果不符合則可以在之後的sprint加以修正（此為回饋機制的意義，有錯則改之）。由於每個sprint週期很短（一般Scrum團隊採用2週至4週的sprint），所以可以避免傳統開發專案在專案晚期客戶才發現問題但卻沒時間加以修正的困境。

Retrospective meeting

軟體開發除了需求可能不符合客戶所需，軟體開發流程本身如果沒有做好管理，也很容易開發出『低品質』的軟體。例如，bugs太多，程式無法擴充，沒有自動化測試等等。所以，在每個sprint結束時，除了review meeting以外，Scrum還有一個稱之為retrospective meeting的活動，用來檢討與軟體開發流程有關的議題。在這個活動中，團隊成員們探討:

1. 那些開發作法是好的，應該要繼續維持下去。例如，有導入持續整合，或是有持續做pair programming；
2. 有那些與開發流程有關的地方沒有做好需要改善的。例如，自動化單元測試做的不夠多，或是測試硬體設備不夠；
3. 擬定改善計畫（action plan）。